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[0001] This application claims priority to U.S. Provisional Application 
No. 60/410,143, which is hereby incorporated by reference. 

BACKGROUND 

[0002] Modern day telecommunications are making the world "a global 
village" such that world-wide communications is substantially real-time. Current 
telephone companies are not only selling regular services, such as telephone or data 
services, but they are also aggressively marketing value-added services. One example 
of a value-added service involves enhanced systems for messaging, such as voice 
mail. A number of other value-added services attempt to converge telephone with 
data. One disadvantage of such services is that each service requires a unique 
telephone number. 

[0003] Another problem with current telecommunications is experienced 
by people that have a variety of communications needs and responsibilities at 
different times. For example, mobile and remote workers have a need to be aware of 
messages; however, if traveling, or in a virtual office, it is quite difficult to check e- 
mail and faxes when they may only have a few minutes at a phone. 

[0004] Current telecommunication systems typically employ servers that 
store and play voice messages, generate and store text messages, and provide 
integrated voicemail and fax mail services. One problem with such servers is that a 
specific telecommunications service exists through a single interface. Accordingly, 
users who utilize other interfaces - e.g., PSTN, Wireless, VOIP and the Internet - may 
be prohibited from accessing and using the telecommunications system for the desired 
service. 

[0005] By way of illustrative example, prior art voicemail services provide 
a caller with an option to deposit a message when the called party does not answer the 
call, is out of range, or has switched off the phone. The storage of these messages is 
within a handset, as in U.S. Pat No. 6,091,947, or on a system server. However, 
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storage of the message at the system server requires that a mailbox be pre-provisioned 
when a user initially subscribes for the service, thereinafter a fixed storage space is 
allocated. This fixed storage space limits the user to the memory space provided and 
the user may fail to receive messages if his system quota has been filled. 

[0006] Other problems with prior art telecommunications are now 
described. By way of example, U.S. Pat No. 6,032,039 describes a notification 
message, which contains a call back number, caller ID, message type, time and date 
received. If the caller has to view the message, he has to dial a distinct common 
number provided to him by the service provider and, then, browse through the inbox 
to access his message. There is no direct way to view a particular message; it 
therefore takes much more time for a user to retrieve a specific message. 

[0007] In conventional voicemail systems with roaming capability, a user 
is required to dial a new number from every roaming location in order to check his or 
her voicemail. It is therefore inconvenient for the user to remember the particular 
number for each location. 

SUMMARY OF THE INVENTION 
[0008] Certain embodiments hereof may overcome certain of the 
problems in the prior art by systems and methods hereinafter disclosed. Under one 
exemplary embodiment, network architecture is provided for use in an integrated 
communications system utilizing PSTN lines, wireless networks, voice over Internet 
protocol, email, facsimile and/or Internet sources. Messages may take the format of 
text (email, SMS, etc.), audio, graphic, image, facsimile, and/or video, for example. 
The architecture may be used, for example, by and between multiple users to 
exchange messages; in one embodiment, the architecture therefore operates to collect 
and store messages, intelligently notify users of new messages and facilitating 
convenient retrieval of messages. 

[0009] Certain embodiments herein may also permit a user (using a first 
interface) to send a message to a recipient user (using a second interface); associated 
architecture dynamically collects, stores, saves, and deletes messages without user 
intervention, irrespective of the interface used. 
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[0010] In certain embodiments, "dynamic mailboxes" are employed to 
store messages. These dynamic mailboxes may include one or more of the following 
characteristics: 

o A mailbox is created only when a user receives the first message, 
o A mailbox is automatically terminated when a user has no new or 

saved messages in his mailbox, 
o A mailbox is deleted when a user ceases to be an active/valid user of the 

system. 

o A mailbox is automatically administered without user intervention, for 
example to delete old messages and/or to make additional space. 

o A mailbox is automatically managed by the system, through 

compression, backup and restoration that creates additional space when 
needed. 

o Mailboxes are provisioned to a scaleable set of users for a given level of 

system resources, 
o A mailbox has Uniform Messaging Service (UMS) functionality, 
o Messages for a mailbox may take different formats, for example voice, 

fax, email, SMS, etc. 
o Based on the user's home location, a mailbox is created on an 

appropriate server to provide synchronization and local access 

facilities. 

[0011] Users of certain systems described herein below may be notified 
using Short Messaging Service (SMS), though other modes of notification may be 
used. 

[0012] In accord with other embodiments herein, an individual message in 
a user's mailbox is assigned a unique message ID number, through which the user 
may selectively listen to a particular message (as opposed to serially scanning 
multiple messages in the mailbox, if desired). Convenient "one step" methodology 
may also be employed, as described below. 

[0013] Certain advantages may be appreciated by systems and processes 
described herein below. In one example, users with different technologies, different 
media and/or different terminals may still communicate with others, anywhere at any 
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time, for example. In another example, voice mail, fax, and e-mail messages may also 
be communicated through a single user interface, thereby simplifying message 
delivery and handling by improving how users receive, reply to, and manage 
messages, regardless of delivery mode. 

[0014] In one embodiment, a process exchanges messages between users. 
Messages from a plurality of user networks having a plurality of network protocols 
are processed for storage in a message store. At least one of the messages in the 
message store is accessed from one of the user networks having any one of the 
network protocols. 

[0015] In one embodiment, a communications system exchanges messages 
between users. A messaging store stores the messages. A messaging server accesses 
messages of the first message store. At least one server interfaces between the 
messaging server and user networks such that the messages are exchanged between 
the users, via the first messaging server and the first messaging store, even if the user 
networks employ a plurality of protocols. 

[0016] In one embodiment, a process selectively retrieves messages for a 
subscriber, including: embedding information about a stored message within a 
notification for the stored message; communicating the notification to a subscriber 
over a network; and responding to interaction between the subscriber and the 
embedded information to communicate the stored message to the subscriber. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0017] FIG. 1 shows one communications system for exchanging 
messages between users. 

[0018] FIG. 2 is a block schematic diagram of network architecture 
suitable for use with the system of FIG. 1. 

[0019] FIG. 3 illustrates exemplary relationships and data flow for the 
network architecture of FIG. 2. 

[0020] FIG. 4 shows exemplary data paths to and from certain components 
of the network architecture of FIG. 2. 

[0021] FIG. 5 illustrates processing by and between certain components of 
the network architecture of FIG. 2. 
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[0022] FIG. 6 illustrates synchronization between servers at a home 
location and at a remote location. 

[0023] FIG. 7 shows one system illustrating scalability of network 
architectures 

[0024] FIG. 8 shows one process for employing dynamic mailboxes. 
[0025] FIG. 9 shows one process for automatically managing a mailbox. 
[0026] FIG. 10 shows one intelligent notification process. 
[0027] FIG. 11 shows one selective message retrieval process. 
[0028] FIG. 12 shows one method for exchanging messages between 

users. 

DETAILED DESCRIPTION OF DRAWINGS 
[0029] FIG. 1 shows one system 100 for exchanging messages between 
users. In one example, system 100 may provide messaging and voicemail. A message 
originates at a message source 112 (e.g., a user communicating messages via a fax 
machine, telephone, computer, phone or cell phone, wireless PDA, as shown). The 
message is, for example, text mail, voice mail, an image, or combinations thereof. A 
network connection 114A links message source 112 to a message processing 
subsystem 116. Network connection 114A is, for example, a telephone line, Internet 
connection, VOIP and/or wireless connection. As described in more detail below, one 
or more message processing subsystems 116 process the incoming messages from 
network connection 114A and deliver the messages to one or more subscribers 120, 
over a network connection 114B. Each subscriber 120 is, for example, a user 
receiving, managing and/or responding to messages through a fax machine, telephone, 
computer, phone or cell phone, or wireless PDA as shown. 

[0030] In one embodiment, message processing subsystems 116 operate to 
screen messages, compress/decompress messages for storage/ playback (such that 
messages are available to subscribers 120), and/or provide protocols to accept 
messages. In one embodiment, the protocols used to accept messages include voice 
prompts and V.29 facsimile protocol. Message processing subsystems 116 may 
further validate and/ or reject messages of subscribers 120 without current accounts, 
reject unwanted messages ("spam"), and/or reject messages that are in a format 
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unacceptable either to the user or a particular installation. In one example, a facsimile 
message from message source 112 is rejected by message processing subsystems 116 
because a particular service provider has yet to provision or activate this system 
feature, or because the intended recipient subscriber 120 has set his or her preference 
to reject facsimile messages, as described below. In one embodiment, service provider 
configurations and user preferences are administered via a configuration and 
maintenance subsystem 126. 

[0031] In one embodiment, during delivery of messages to subscribers 
120, message processing subsystems 116 transforming speech-to-text, text-to-speech, 
and/or encode an analog message for digital storage. In another embodiment, message 
processing subsystems 116 contain ancillary features to track activities for billing 
and/or manage system configuration that will be respectively accomplished by billing 
subsystem 124 and configuration and maintenance subsystem 126, as shown. 

[0032] Once a message has been received, messaging processing 
subsystems 116 store and track the message in internal databases (see FIG. 2). A 
subscriber notification subsystem 118, connected with subsystems 116, may then 
format a notification with information regarding the stored message - such as caller 
name, caller number, and time of call, message ID - and send the notification to 
subscriber 120 informing the user of the message. Subscriber 120 may then interact 
with a message management subsystem 122, connected to subsystems 116 and to 
subscriber 120 through a network 114C, to retrieve, delete and/or otherwise manage 
his or her messages. 

[0033] FIG. 2 is a block schematic diagram of network architecture 
suitable for use with system 100 (and, in particular, message processing subsystems 
116, subscriber notification subsystem 118, message management subsystem 122, and 
billing subsystem 124) of FIG. 1. A first layer 209 of this architecture is the 
'interface' layer (i.e., the 'front-end'). Through layer 209, system 100 may 
receive/transfer messages via one or more different network connections 204, for 
example Public Switched Telephony Network (PSTN) lines 200, Wireless networks 
201, Voice over Internet Protocol (VOIP) 202 and/or the Internet 203. Layer 209 thus 
incorporates different protocols that enable system 100 to communicate with network 
connections 204 and over different network protocols. Users of system 100 may thus 
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communicate through different networks and protocols at different times, and 
exchange messages across different networks and protocols. 

[0034] In one embodiment, layer 209 incorporates a fax server 205 to 
enable fax messaging functionality using PSTN lines 200. Such fax messages may be 
stored in a message store 215 as SMTP/ MIME messages with fax data as attachment, 
enabling users to access these fax messages via the Internet over TCP/IP protocol, for 
example. Access to the fax messages is for example enabled through a web server 
207, which provides a graphical user interface. A subscriber 120 thus has the option 
of accessing fax messages via a telephone over a PSTN 200 network; in this case, that 
subscriber 120 also has the ability to access and manage the fax messages, and, 
optionally, to forward a fax message to another number, such as another mailbox or a 
fax machine. 

[0035] In one embodiment, voice messages through PSTN lines 200, 
Wireless Networks 201 and/or VOIP 202 are routed to an Interactive Voice Response 
(TVR) unit 206, which provides a telephone user interface to access and manage 
appropriate mailbox(es). IVR 206 conmiunicates with a "back-end" layer 218 of the 
network architecture of FIG. 2 through a messaging gateway 214, with data 
encapsulated in XML documents, for example. 

[0036] In one embodiment, messages from Internet 203 are directed to 
web server 207 through Internet protocols. Access to a subscriber's mailbox is thus 
also provided through the Internet protocols and web server 207. In this example, web 
server 207 may also provide a graphical user interface for the subscriber to access and 
manage his/her mailbox, irrespective of the type of messages within the mailbox, be it 
email, fax, voicemail, etc. In one embodiment, a notification server 208 (for example 
operating as subscriber notification subsystem 118, FIG. 1) notifies subscribers 120 of 
messages. Notification server 120 for example operates whenever a user needs to be 
notified that a new message has arrived in his/her mailbox, when a new service is 
activated, and/or when a user needs to be prompted for action. In one example, newly 
arrived messages trigger notifications to the user through a message-waiting indicator, 
a stutter tone audio indicator, and/or as a short message service (SMS) notice on a 
mobile phone or pager. In the case of notification through SMS, notification server 
208 sends out an intelligent notification, which is described in more detail in 
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connection with FIG. 10. "One-Step" retrieval of the message by the subscriber may 
be provided, as described in more detail in connection with FIG. 11. 

[0037] Messaging gateway 214 is thus a second layer in the network 
architecture of FIG. 2. In one embodiment, messaging gateway 214 contains certain 
core functions enabled by a messaging server 211, billing/ reporting server 213, 
directory/authentication server 213, and/or other utility services such as TTS/ ASR 
servers 210. TTS/ ASR servers 210 provide text-to-speech and automatic speech 
recognition processes. Messaging server 211 provides access to message store 215 for 
message storage, access, retrieval and management. Directory/ authentication server 
212 cooperates with messaging server 211 to authenticate access to services and to 
implement system configuration, class of service, and/or service management 
functions. Billing/reporting server 213 functions to create and store CDRs (Call 
Detail Records), and may further provide for customizable reports. Web server 207 
may further provide a web-based interface to billing/reporting server 213, if desired, 
enabling service providers to access and manage CDRs to generate billing data and 
reports. 

[0038] In one embodiment, a back end layer 218 of the network 
architecture of FIG. 2 contains data/information for system 100. In one embodiment, 
layer 218 includes message store 215, directory/ user profile store 216, 
synchronization server 217, and/or other servers (e.g., server 219) to store information 
such as configuration data, system logs, and usage logs. Back-end layer 218 may be 
shielded from direct interfaces with user applications. In one embodiment, therefore, 
layer 218 interfaces with the "outside" world through standard protocols administered 
by separate servers; this enables server deployment to be scaled upwards to meet 
increasing traffic volume by distributing workload across separate servers. 

[0039] Message store 215 collects and organizes messages in mailboxes. 
In one embodiment, message store 215 is organized with indexing such that messages 
are efficiently deposited, managed and retrieved. In one embodiment, message store 
215 collaborates with directory/authentication server 212 to provide authenticated 
access to the mailboxes and to ensure that mailboxes are accorded the proper grades 
of service based on user, message type, and other parameters. 
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[0040] In one embodiment, directory/ user profile store 216 contains user- 
related information, such as user profiles, preferences, and access/ authentication 
/service attributes for all users; and synchronization server 217 enables message and 
data synchronization between various nodes in the network, thereby enabling roaming 
functionality to user access and management of the mailbox from any network in the 
node. Accordingly, when a subscriber is roaming, his/her messages are copied to 
server in the roaming location (see FIG. 6); this enables the subscriber to access 
his/her mailbox even while roaming. In order to facilitate the roaming functionality, 
subscriber preferences are also replicated in the roaming location so that the 
subscriber has consistent access to his/her mailbox. The data and messages replicated 
in server 217 are kept in the roaming location for the duration of roaming. That is, 
when the user returns to the home location (see FIG. 6), the data at the roaming 
location may be deleted. 

[0041] FIG. 3 is a block diagram illustrating exemplary relationships (and 
data flow) for the network architecture of FIG. 2. In one example, if a call made to a 
subscriber 120 is unanswered, IVR 206 receives the call. In the example, IVR 206 
first sends requests to directory/authentication server 212 to collect subscriber profile 
information and the subscriber's mailbox/message preferences. Once identifying data 
for the call is collected (e.g., Caller ID, Called number, and reason call forwarded, 
etc.), IVR 206 requests that messaging server 211 encode, compress and then format 
the message, for storage in a desired location (e.g., within message store 215). 

[0042] In another example of FIG. 3, IVR 206 requests that billing and 
reporting server 213 log message and call data; this data is later used for billing and 
reporting purposes according to specified service parameters and rates. This billing 
may be set according to (a) the amount of memory used to store data for a particular 
subscriber 120 or (b) a fixed monthly subscription rate, for example. 

[0043] In one embodiment, an administration and configuration server 305 
is provided, for example as another server of gateway 214, FIG. 2. Administration and 
configuration functions of server 305 may be accessed via a web interface through 
web server 207, for example. Server 305 provides for provisioning, system 
configuration, administration, monitoring, and/or user management functions. User 
preference data and system configuration stored in server 305 may be used in the 



406293 



9 



automated management of mailboxes, the details of which are described in more 
detail in connection with FIG. 9. 

[0044] FIG. 4 shows, in one embodiment, exemplary data paths to and 
from certain components of the network architecture of FIG. 2. When a call remains 
unanswered, a switch 400 (e.g., associated with PSTN network 200, FIG. 2) transfers 
the call to IVR 206 over data path 401 using, for example, a E1/C7 or T1/SS7 
protocol (implemented by IVR 206 using telephony hardware). IVR 206 then answers 
the call, greets the caller using a customizable preset user greeting, and invites the 
caller to leave a message for the user. That message is digitized, compressed and 
encoded to a sound file format (e.g., a Resource Interface File Format (RIFF) wav 
file). In one embodiment, IVR 206 optionally implements message caching such that 
IVR 206 retains a local copy of a message in local storage space (the message being a 
copy also sent to message store 215). The message caching facilitates faster access to 
the message and reduces latency associated with subscriber accesses to the message. 
The size of memory cache within IVR 206, and the duration of local storage are all 
configurable through administrative and configuration server 305, FIG. 3. 

[0045] Those skilled in the art appreciate that switch 400 may be 
illustrative and may comprise a mobile switching center incorporating many physical 
switches. 

[0046] Continuing with the example of FIG. 4, IVR 206 deposits the 
received message in message store 215 over data paths 403 and 405. This is 
accomplished by initiating a request to messaging server 211 which in turn interacts 
with message store 215 to deposit the message. Messaging server 211 is for example 
accessed via HTTP protocols using XML/JAVA. The message is then compressed, 
encoded, and composed in SMTP/MIME format - with the voice part as the 
attachment, for example - and sent to message store 215 for storage and subsequent 
retrieval. Once the message is deposited in message store 215, messaging server 211 
populates a queue 407 with data about the arrival of the new message. Notification 
server 208 scans through data in queue 407 to send out notifications to appropriate 
subscribers 120. FIG. 4 also illustrates data path 407, connecting rVR 206 with 
directory and authentication server 212, and data path 409, connecting server 212 with 
profile store 216. 
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[0047] FIG. 5 illustrates processing by and between certain network 
architecture components of FIG. 2, in accord with one embodiment. When a call is 
unanswered, switch 400 (FIG. 4) transfers the call to IVR 206. The first stage of IVR 
206 includes low-level telephony drivers 505; these drivers answer calls, configure 
the number of rings to answer, collect the caller ID and signal the end of recording. 
Telephony drivers 505 work in conjunction with the high level software programs that 
answer calls, record information, utilize called IDs, and transfer calls. 

[0048] Continuing with the current embodiment, the next stage of IVR 
206 is the call control library 504, which handles different network interfaces and 
signaling protocols, for example E1/C7 or T1/SS7 communication links between 
telephony hardware and switch 400 used to connect between the local telephone 
network and a common call control programming and protocol environment. Library 
504 implements functions that are common to interface-specific libraries in a 
consistent manner, and translates and routes application requests to the appropriate 
application interface 503. Application interface 503 provides connectivity between 
call control library 504 and higher-level application processes such as logging 
services 501 and messaging services 502: logging services 501 represents a process or 
set of processes that create and deposit call log data (e.g., CDR), usage data and 
system log data in message store 215 (voice messages may also be stored with 
indexing data); messaging services 502 capture, compress and format the recorded 
message for storage in message store 215. In the example, voice messages are 
deposited and retrieved in compressed form and decompressed for playback using 
appropriate compression/ decompression techniques 

[0049] In the embodiment, of FIG. 5, directory/user profile database 216 
stores user profiles, mailbox profiles, as well as other transient and configuration data. 
It implements profiling schema that may be used to provide various messaging 
services. In addition to user profiles, usage data, system logs and configuration data 
may also be stored in database 216 of FIG. 5, including, for example: 

• Telephony Services Parameters 

o Type of Channel 
o Number of Channels 

• Parameters for messaging service process 502 
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o Maximum message size 

o Maximum number of messages 

o Maximum number of days to store messages 

• Parameters for databases 216, 217, and 219 

o Database Server name 
o Database Port number 

• Voice compression parameters 

• Parameters for notification services 508 

• SMS protocol parameters 

o SMS Port Number 
o Stutter Tone 
o Dial-out 
o Email 

• Parameters for logging services 501 

o Log Directory 

o Rotation parameters 

[0050] In one embodiment, notification services 508 utilize short 
messaging service (SMS) to implement intelligent notification, which is further 
described below with respect to FIG. 10. Notification server 208 thus implement 
various SMS protocols - such as SMPP/CIMD2/HTTP or SMTP interfaces - to 
communicate with short messaging service centers (SMSC) 509 (typically over 
TCP/IP). These protocols facilitate sending and receiving messages to/from the 
subscriber's mobile phones. 

[0051] In the current embodiment, notification server 208 checks for new 
message entries for which notifications have not been sent and gathers information 
(e.g., caller identification (ID), time, length, etc.) about such messages based on 
Message IDs. It then sends SMS messages - including the Access Number (stored in 
database 219), Caller ID and Message ID - and updates a notification table within 
notification server 208. The notifications are then passed onto SMSC 509, which 
sends and receives SMS messages to the subscriber's mobile phone. 

[0052] FIG. 6 illustrates synchronization between servers 217 at a home 
location 600 and at a remote location 601, in accord with one embodiment. Each 
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location 600, 601 includes like components (e.g., synchronization server 217 and IVR 
206, FIG. 2 - FIG. 4), as shown. A radio tower 602 illustratively beams and receives 
signals to and from mobile phones 603, as shown. A Mobile Switching Center (MSC) 
400 performs the switching of calls between the mobile users, and between mobile 
and fixed network users (i.e., the respective switch 400 at location 600 and 601 serves 
to route/forward calls to the appropriate terminating number). If a call is left 
unanswered, IVR 206 receives the call and guides the caller(s) to voice message 
functionality as described above (e.g., as illustrated in FIG. 6 by notification server 
208, message store 215, IVR 206 and synchronization server 217). 

[0053] In one embodiment, therefore, similar network architecture (to the 
architecture at locations 600, 601) is provided at all locations in the telephony 
network. When constructed in this manner, synchronization server 217 enables 
message and data synchronization between nodes (each node for example represented 
by MSC 400) so as to enable roaming functionality to the user, who can then access 
and manage his or her mailbox from any network in the node In FIG. 6, 
synchronization servers 217 are also responsible for synchronizing user profile 
information 609 (e.g., profile database and message store synchronization data based 
on user's current location) and text, audio, video and voice messages 610 between the 
home and roaming locations 600, 601. When a user (i.e., a subscribed to system 100, 
FIG. 1) roams in another location, therefore, he is notified (by notification server 208) 
of voicemail. The user may then dial in to message store server 215 at the roaming 
location and retrieve his message. This is made possible due to the synchronization by 
and between servers 217, which enables the user to maintain access and stay updated 
with voicemails even while roaming. For a user who is at 'roaming' location 601 (i.e., 
a location within our outside of the country and away from his/her 'home' location 
600), server 217 at 'home' location 600 synchronizes with server 217 at 'roaming' 
location 601 to facilitate easy user access to his/her mailbox. 

[0054] FIG. 6 further illustrates that a user may instantly reply to a 
received voicemail. Consider a first user on a first telecommunications service 
provider communicating voicemail to a second user on a second telecommunications 
service provider. In this example, the second user is given an option to reply to the 
voicemail message when he/she listens to the message. The reply message is recorded 
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and sent across a wireless network 610 to the first user. Network 610 is synchronized 
with server 217 at home location 600. 

[0055] Those skilled in the art appreciate that databases such as illustrated 
in the various figures may represent logical storage incorporating multiple physical 
storage devices. For example, FIG. 6 shows a database 500 which, for example, may 
store selective data elements of message store 215, if desired. 

[0056] FIG. 7 illustrates one system 700 showing scalability of network 
architectures described hereinabove, in accord with one embodiment. Since system 
700 is based on an "open" architecture, it may be scaled to include more components 
whenever needed. The open architecture also facilitates compatibility with other 
existing systems or components in the service providers' network. Specifically, with 
increasing numbers of subscribers or messages, or message size, additional message 
store(s) 215, database(s) 500, notification server(s) 208, IVR 206 and signaling 
interfaces 704 are added as needed, such as shown in FIG. 7. In FIG. 7, MSC 400 
communicates with IVR 206 and signaling interface 704 through the SS7 protocol, 
while TCP/IP is used for communication between messages store(s) 215 and 
database(s) 500, notification server(s) 208, IVR 206 and SMSC 509. 

[0057] FIG. 8 is a flow chart illustrating one process 800 for employing 
dynamic mailboxes. Process 800 is for example implemented by system 100, FIG. 1. 
When a call to a subscriber remains unanswered, the call is forwarded by switch 400 
to system 100. System 100 then receives 801 the call and obtains 802 relevant 
information about the call, such as the caller ID and the called number (ANT). The 
caller is then greeted 803 with a message, for example saying that they have reached 
the voice mailbox of the subscriber (identified for example either by the subscriber 
name, if recorded and available in system 100, or the phone number) and prompting 
the caller to leave a message for the subscriber. If 804 the caller records a message, 
the message is accepted and stored 805 (along with associated Caller ID and the ANT) 
in a temporary storage location. Then, the user profile database is queried 806 to 
verify if the subscriber (identified by ANI) already has a mailbox within system 100. 
If so, the message is deposited 807 in the existing mailbox. 
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[0058] If 806 the subscriber does not have a mailbox in system 100, a 
mailbox is created and populated 808 with default profile values; the message is then 
deposited 807 in the newly created mailbox. 

[0059] Once the message is deposited 807 in the appropriate mailbox, the 
subscriber's roaming status and location is obtained 809 from switch 400 or from the 
registry on the carrier network. If 810 it is established that the subscriber is roaming 
(e.g., at roaming location 601, FIG. 6), then a request is sent to system 100 at the 
roaming location to create 811 a mailbox for the subscriber, the mailbox being 
initialize with default values. 

[0060] The message from the mailbox at the home location (e.g., location 
600, FIG. 6) is then appropriately transferred or copied 812 to the roaming location by 
invoking the mailbox synchronization process, such as described in connection with 
FIG. 6. 

[0061] FIG. 9 is a flow chart showing one process 900 of automatically 
managing dynamic mailboxes. The process of FIG. 9 is for example implemented by 
system 100, FIG. 1. Process 900 may run at a configurable time interval, or may be 
invoked by system 100 based on certain events, for example if a drop in the level of 
available free system resources occurs below set tolerances. Process 900 begins with 
obtaining 901 relevant system level parameters such as maximum number of days, 
maximum number of messages, mailbox size, incremental size, etc., from 
configuration data in database 219, FIG. 2. Process 900 may sequentially access and 
analyze each user mailbox in system 100 within a target range (the 'target range' 
defines one or more mailboxes, or all mailboxes, as a set of mailboxes to be processed 
in process 900), as indicated by step 914. For each user, the profile and the 
corresponding mailbox data is retrieved 902 from database 216. If 903 the user's 
status is inactive, then the entire mailbox is deleted 904; otherwise the mailbox is 
further analyzed and administered per steps 905-913. 

[0062] In step 905, all expired messages in the mailbox (e.g., all messages 
older than a specified number of days determined by system parameters) are purged 
from the mailbox. The size of the mailbox is then determined 906 based on the type, 
number, state, and size of the messages and compared with the allocated maximum 
size. If 907 the size of the mailbox is within allocated limit, no action is taken; 
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however, if the mailbox size has exceeded the allowed limit, or is close to the limit, 
each saved message in the mailbox is checked 908 for date/time of the last access. If 
909 a saved message has not been accessed by the users for a specified number of 
days, the message is added 910 to backup/archival storage (e.g., within message store 
215). All other saved messages are compressed 911, thereby reducing mailbox size. 

[0063] If 912 the size of a mailbox does not collapse below the allowable 
limit, after the above actions, additional resources are allocated 913 to the mailbox 
based on the user profile, including, for example, the type of the service(s) the user 
has subscribed and the number and type of messages relevant to such services. After 
all user profiles and associated mailboxes in the target range specified by process 900 
are analyzed and administered, process 900 ends. 

[0064] FIG. 10 shows one intelligent notification process 1000 that is for 
example optionally employed by system 100, FIG 1, to inform users of new messages 
or to remind users of messages that have not been accessed through SMS text 
messages. 

[0065] Process 1000 begim, with obtaining 1001 system level parameters, 
such as home location, access/callback numbers, message types, time intervals for 
message notifications, etc., from configuration data in database 219, FIG. 2. Message 
data (e.g., metadata for all messages that is stored in database 215) is then (a) scanned 

1002 for either all new messages that have arrived at system 100 and/or (b) scanned 

1003 for any messages that have not been accessed by the user for a specified number 
of days after initial notification. From steps 1002, 1003, a list of messages (message 
queue) is compiled 1004 that require notifications be sent to respective recipient 
subscribers. 

[0066] For each message that requires user notification (either a new 
notification or a reminder notification), associated information - such as user ID, 
caller ID, message ID (which is unique ID associated with each message in a user's 
mailbox), message date/time, message type, message length - is collected 1005 from 
database 215, FIG. 2. Through user IDs, the profile of a user associated with a 
message is then queried 1006 to determine any user-specific notification parameters 
that may have been set. Thereafter, the user's roaming status is determined 1007 by 
querying switch 400 or the registry within the respective carrier network. If 1008 the 
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user is roaming, then the associated current callback number for the roaming location 
is obtained 1009 from system configuration of the roaming location; otherwise the 
callback/access number for the home location is obtained 1010 from system 
configuration parameters for the home location. Once necessary information for a 
message is available, as described above, an appropriate notification text message is 
compiled 1011 from a message template for a given message type. Information 
associated with the message - such as the callback number, message ID, message 
date/time/type/size - is then embedded 1012 in the notification text forming a 
complete intelligent notification SMS text message for the user. The SMS text 
message is then sent 1013 to the user by connecting to the SMSC 509 associated 
therewith and by using appropriate protocols (such as described in connection with 
FIG. 3). 

[0067] FIG. 11 shows one message retrieval process 1100 including 
'selective one-step retrieval' of messages. Process 1100 may be implemented, for 
example, by system 100, FIG 1. In the example of FIG. 11, when a user receives an 
SMS notification through intelligent notification process 1000, FIG 10, the user has 
the option to call back 1098 the number embedded in the SMS message (along with 
the message ID) using the 'use number' option on mobile phone or by directly dialing 
the access number for message retrieval from any phone. When the user calls back 
using either such option, the call is forwarded 1099 by switch 400 to system 100 (in 
this example), which then collects 1101 available information for the forwarded call, 
such as the ANI, caller ID, message ID. 

[0068] In step 1102, the presence of caller ID is checked. If 1102 the caller 
ID is present, then it is compared 1103 with the ANI. If 1103 those two values match, 
it denotes that the user is calling his or her own number to retrieve messages. If 1104 
the message ID is also available, then the message corresponding to the message ID is 
played 1105 for the user. Accordingly, steps 1102-1105 represent selective one-click 
message retrieval whereby a message is conveniently retrieved by a user by pressing 
the callback number embedded in the SMS notification sent to them. 

[0069] If 1104 a message ID is not available, then the outstanding 
notifications are checked 1107 to see if the user - identified by the caller ID - has any 
messages pending. In case pending notifications are found, the message ID associated 
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with the first pending notification is retrieved 1108 and the corresponding message is 
played 1105 for the user. If 1107 no pending notifications are found, the user's 
mailbox is queried 1109 to check if any new messages are pending for the user. If 
1109 messages are pending, the message ID for the first new message in the mailbox 
is retrieved 1110 and the corresponding message is played 1105 to the user. If 1109 
no pending messages are found, the user is prompted 1106 to choose other options, 
such as to listen to saved messages. 

[0070] If 1103 the ANI and the caller ID are both available, but the values 
do not match, then the caller ID is validated 1111 to see if it belongs to a valid/active 
user of system 100. If 1111 the caller ID is not a valid user ID, then further access is 
denied (e.g., process 1100 ends). If 1111 the caller ID is a valid user ID, then step 
1112 determines whether to authenticate the call (step 1112 can be determined by 
system configuration parameters or by the user profile associated with the caller ID). 
If 1112 yes, the user is prompted 1113 for a PIN. The caller is then authenticated 1114 
using the caller ID and the entered PIN. The user is granted further access (to step 
1104) only if authentication 1114 succeeds or if the system and/or user profile do not 
require authentication. 

[0071] After the user has been authenticated 1114, process 1100 checks 
1104 for the availability of a message ID. If 1104 the message ID is available, then 
the message corresponding to the message ID is played 1105 for the user, as above. If 
1104 the message ID is not available, then process 1100 continues with step 110, as 
above. 

[0072] If 1102 the caller ID is not available for the call, then the user is (a) 
prompted 1115 to enter a phone number and (b) prompted 1116 to enter a PIN, both 
used to authenticate the user. If 1117 user authentication is successful, then process 
1100 continues with step 1107 as shown. 

[0073] FIG. 12 shows one process 1200 for exchanging messages between 
users. Process 1200 is for example implemented by system 100, FIG. 1. In step 1202, 
messages from a plurality of user networks having a plurality of network protocols are 
processed for storage in a message store. In step 1204, at least one of the messages in 
the message store is accessed from one of the user networks having any one of the 
network protocols. 
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[0074] Changes may be made in the above methods and systems without 
departing from the scope hereof. It should thus be noted that the matter contained in 
the above description or shown in the accompanying drawings should be interpreted 
as illustrative and not in a limiting sense. The following claims are intended to cover 
all generic and specific features described herein, as well as all statements of the 
scope of the present method and system, which, as a matter of language, might be said 
to fall there between. 
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